The present invention relates generally to the field of software and in particular to a method of automatically generating policy recommendations for roles based on the entitlements and non-entitlement attributes of identities.
Role based control systems comprise an emerging and promising class of control systems that simplify and streamline the control task by elevating system control rules and decisions from the individual user or process level to a group level. In particular, the grouping of identities in a role based control system reflects the roles the corresponding individuals have as part of an organization that owns, controls, and/or manages the system. Control rules and decisions may then be assigned and managed at the role level rather than the individual level, greatly simplifying management and control of the systems.
A common application for role based control systems, and an application used to explain the present invention, is Role Based Access Control (RBAC). With respect to RBAC, access is defined as the ability to utilize a system, typically an Information Technology (IT) resource, such as a computer system. Examples of ways one may utilize a computer include executing programs; using communications resources; viewing, adding, changing, or deleting data; and the like. Access control is defined as the means by which the ability to utilize the system is explicitly enabled or restricted in some way. Access control typically comprises both physical and system-based controls. Computer-based access controls can prescribe not only which individuals or processes may have access to a specific system resource, but also the type of access that is permitted. These controls may be implemented in the computer system or in external devices.
With RBAC, access decisions are based on the roles that individual users have as part of an organization. Users take on assigned roles, such as for example, engineer, manager, and human resources (HR) personnel. Access rights are grouped by role name, and the use of resources is restricted to individuals authorized to assume the associated role. For example, an HR employee may require full access to personnel records from which engineers should be restricted to preserve privacy, and engineers may require full access to technical design or product data from which HR employees should be restricted to preserve secrecy, while engineering managers require limited access to both types of data. Rather than set up (and maintain) each individual employee's access controls to the personnel and technical data, the organization's access control policies may be more easily managed under RBAC by defining three roles: HR, engineer, and manager. All individuals in the organization who perform the associated role are grouped together, and IT access policies are assigned and maintained on a per-role basis.
The use of role policies to implement access control can be an effective means for developing and enforcing enterprise-specific security policies, and for streamlining the security management process. User membership into roles can be revoked easily and new memberships established as job assignments dictate. New roles and their concomitant policies can be established when new operations are instituted, and old roles can be deleted as organizational functions change and evolve. This simplifies the administration and management of privileges; roles can be updated without updating the privileges for every user on an individual basis.
The current process of defining roles and assigning policies to the roles, often referred to as role engineering, is based on an analysis of how an organization operates, and attempts to map that organizational structure to the organization's IT infrastructure. This “top-down” process requires a substantial amount of time and resources, both for the analysis and implementation. The prospect of this daunting task is itself a significant disincentive for organizations using traditional access control methods to adopt RBAC.
Co-pending application 10/741,634 discloses an automated “bottom-up” role discovery process that exhibits numerous advantages over the traditional top-down role engineering methods. Broadly speaking, existing roles in the organization are discovered in this process by an analysis of entitlement information pertaining to the organization's IT infrastructure. That is, access roles are discovered by an analysis of the existing IT system security structure. For example, user entitlement data—the systems, programs, resources, and data that a user has permission to access or modify—as well as other user attributes such as name, hire date, work location, and the like, may be extracted for each user or identity. Identities with the same or similar entitlements may then be intelligently clustered into groups that reflect their actual, existing roles within the organization. The users' common individual entitlements may then be more easily managed by assigning the entitlements to the role. The bottom-up method of role discovery avoids the significant investment in time and effort required to define roles in a top-down process, and also may be more accurate in that it reflects the actual, existing roles of users in the organization, as opposed to an individual's or committee's view of what such roles should look like. Another significant advantage to the bottom-up role discovery process is that it may be automated, taking advantage of powerful data mining tools and methodologies.
However, even when roles are automatically formed by the clustering of identities into roles based on entitlements, the formulation of an appropriate policy for the role requires human effort in analyzing the role with respect to the entitlements each identity has in the role, and the various attributes of the identities. A policy specifies which entitlements should be automatically granted to a new identity added to the role and which entitlement(s) should be withheld pending some qualification or approval. This policy formulation requires human effort in analyzing the role with respect to the entitlements that each identity has in the role, and the various attributes of the users, to determine which entitlements should be automatically granted by means of the policy to any new identity who becomes part of the role.